Network congestion means that an excessively large quantity of packets are transferred in a network but there are limited resources for storing a forwarding node in the network, causing deterioration in network transmission performance. When network congestion occurs, a phenomenon such as a data loss, an increased delay, or a reduced throughput usually occurs. When network congestion is severe, congestion collapse is caused. As a traffic volume of high-throughput-rate applications (for example, online audio and video playback applications) increases rapidly, a data volume that needs to be transmitted by using a network also grows sharply; therefore, the network is required to maintain a high throughput. If a congestion control measure used to coordinate network resources is inappropriate, even if a network bandwidth is sufficient, high-throughput-rate applications cannot be utilized effectively.
The Transmission Control Protocol (TCP) is a reliable connection-oriented and byte-stream-based transport layer communications protocol, and is defined in RFC 793 of the IETF. Ever since the TCP appeared, many researchers have proposed a series of TCP congestion control mechanisms with the purpose of setting self-adjustment and recovery mechanisms to ensure that load cannot exceed a maximum capability of a network. TCP congestion control includes congestion avoidance and congestion recovery. The congestion avoidance is a prevention mechanism for preventing a network from entering a congested state as much as possible and enabling the network to keep working in a high-throughput and low-delay state. The congestion recovery is a recovery mechanism for recovering a network from a congested state and enabling the network to re-enter a high-throughput and low-delay state even if congestion already occurs.
So far, in a mature implementation manner of the TCP congestion control, a size of a congestion window (CWND) is adjusted to control a throughput of TCP packets. A size of a congestion window refers to a maximum quantity of TCP data packets that can be sent within one round-trip time (RTT). A larger size of a congestion window indicates a higher data sending rate and a higher throughput, but a higher possibility that network congestion occurs. In contrast, a smaller size of a congestion window indicates a lower data sending rate, a lower throughput, and a lower possibility that network congestion occurs. For example, when a congestion window is a 1 maximum segment size (MSS), each time one packet is sent, a receiver needs to send an acknowledgment, and then a second packet can be sent. This definitely prevents network congestion, but a throughput is extremely low. The TCP congestion control is to obtain an optimal congestion window value through adjustment, to maximize a throughput without causing congestion. At present, with an increase in a requirement for a throughput, there are already multiple mature window adjustment algorithms, including a Reno algorithm, a CUBIC algorithm, and the like.
For example, the Reno algorithm is the most widely used and mature TCP congestion control algorithm. A slow start mechanism, a congestion avoidance mechanism, a fast retransmit mechanism, and a fast recovery mechanism that are included in this algorithm are the bases of many existing algorithms. In an operation mechanism of the Reno algorithm, to keep a dynamic balance, a loss of a particular quantity of TCP data packets needs to be generated periodically, and an Additive Increase Multiplicative Decrease (AIMD) mechanism (that is, additive increase, multiplicative decrease) is also provided. Reduction in a congestion window caused by a loss of one TCP data packet needs to be recovered for a relatively long time, and bandwidth utilization is not high. Especially, in a case of a large congestion window, such a disadvantage is more obvious. For the Reno algorithm, when a loss of one TCP data packet is detected, a congestion window is immediately reduced to half in size. In a congestion recovery stage, after an RTT of data transmission in each congestion window, the congestion window is increased by 1 MSS (that is, an increase is 1 MSS), and it takes a relatively long time to perform recovery from the half of the size of the congestion window that exists when the TCP data packet is lost. For example, if a network has a network bandwidth of 100 Mbit/s and a delay of 100 milliseconds, when a throughput approaches the network bandwidth, a congestion window value is approximately 863 MSSs, and 431 rounds of RTTs are required by using the Reno algorithm, so that the congestion window that exists when the TCP data packet is lost can be recovered from the half of the size, and approximately 43.1 seconds are taken. Compared with the Reno algorithm, the CUBIC algorithm has made an improvement in the aspect of growth of a congestion window. In the CUBIC algorithm, a congestion window that exists when a TCP data packet is lost is recorded. When the recorded congestion window is not reached, the window grows in an exponential manner similar to that in a slow start. When the recorded congestion window is about to be reached, an increase step size of the congestion window is greatly reduced. After the increase step size, obtained after reduction, of the congestion window is kept for a period of time, the increase step size of the congestion window is readjusted to approximately exponential rapid growth. If the period of time is only kept occasionally, in the CUBIC algorithm, when the congestion window still grows rapidly after the period of time, more TCP data packets are inevitably lost as network congestion occurs again, further causing deterioration in a network state.
Therefore, the two algorithms (including the Reno algorithm and the CUBIC algorithm) for the TCP congestion control have a same disadvantage as follows: A congestion window grows according to a preset fixed value, and a current desirable network bandwidth cannot be effectively utilized, or even an adjustment policy that is contradictory to an actual network state may be used during adjustment of a congestion window, thereby affecting a requirement of an application for a throughput.